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Description 



Information Messaging and 
Collaboration System 

Cross Reference to Related Applications 

[0001] The present application is related to and claims the bene- 
fit of priority of the following commonly-owned, 
presently-pending provisional application(s): application 
serial no. 60/481,287 (Docket No. SYB/0094.00), filed 
August 25, 2003, entitled "Information Messaging and 
Collaboration System", of which the present application is 
a non-provisional application thereof. The present appli- 
cation is related to the following commonly-owned, 
presently-pending application(s): application serial no. 
09/780,993 (Docket No. SYB/0090.03), filed February 8, 
2001, entitled "System and Method for Dynamic Content 
Retrieval". The disclosures of each of the foregoing appli- 
cations are hereby incorporated by reference in their en- 
tirety, including any appendices or attachments thereof, 
for all purposes. 



Copyright Statement 



[0002] A portion of the disclosure of tiiis patent document con- 
tains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile re- 
production by anyone of the patent document or the 
patent disclosure as it appears in the Patent and Trade- 
mark Office patent file or records, but otherwise reserves 
all copyright rights whatsoever. 
Appendix Data 

[0003] Computer Program Listing Appendix under Sec. 1.52(e): 
This application includes a transmittal under 37 C.F.R. 
Sec. 1.52(e) of a Computer Program Listing Appendix. The 
Appendix, which comprises text file(s) that are IBIVI-PC 
machine and IVIicrosoft Windows Operating System com- 
patible, includes the below-listed file(s). All of the mate- 
rial disclosed in the Computer Program Listing Appendix 
can be found at the U.S. Patent and Trademark Office 
archives and is hereby incorporated by reference into the 
present application. 

[0004] Object Description: SourceCode.text, created: 8/14/2003 
8:29am, size: 3.98KB; Object ID: File No. 1; Object Con- 
tents: Source Code. 



Background of Invention 



[0005] 1. Field of the Invention 

[0006] The present invention relates generally to information 

processing environments and, more particularly, to an in- 
formation messaging and collaboration system providing 
methodology for dynamic collection and forwarding of in- 
formation among system components enabling such com- 
ponents to process the information, modify their contents, 
and take action based on the information. 

[0007] 2. Description of the Background Art 

[0008] Computers are very powerful tools for storing and provid- 
ing access to vast amounts of information. The first per- 
sonal computers were largely stand-alone units with no 
direct connection to other computers or computer net- 
works. Data exchanges between computers were mainly 
accomplished by exchanging magnetic or optical media 
such as floppy disks. Over time, more and more comput- 
ers were connected to each other and exchanged infor- 
mation using Local Area Networks ("LANs") and/or Wide 
Area Networks ("WANs"). Initially such connections were 
primarily amongst computers within the same organiza- 
tion via an internal network. More recently, the explosive 



growth of the Internet has provided access to tremendous 
quantities of information from a wide variety of sources. 

[0009] The Internet comprises a vast number of computers and 
computer networks that are interconnected through com- 
munication links. The World Wide Web (WWW) portion of 
the Internet allows a server computer system to send 
graphical Web pages of information to a remote client 
computer system. The remote client computer system can 
then display the Web pages in a Web browser application 
(e.g., Netscape Navigator or Microsoft Internet Explorer). 
To view a specific Web page, a client computer system 
specifies the Uniform Resource Locator ("URL") for that 
Web page in a request (e.g., a HyperText Transfer Protocol 
("HTTP") request). The request is forwarded to the Web 
server that supports that Web page. When that Web server 
receives the request, it sends the specified Web page to 
the client computer system. When the client computer 
system receives that Web page, it typically displays the 
Web page using a browser application. 

[0010] Currently, Web pages are typically defined using Hyper- 
Text Markup Language ("HTML"). HTML provides a stan- 
dard set of tags that define how a Web page is to be dis- 
played. When a user indicates to the browser to display a 



Web page, the browser sends a request to the server com- 
puter system to transfer to the client computer system a 
HTML document that defines the Web page. When the re- 
quested HTML document is received by the client com- 
puter system, the browser displays the Web page as de- 
fined by the HTML document. The HTML document con- 
tains various tags that control the displaying of text, 
graphics, controls and other features. The HTML docu- 
ment may also contain URLs of other Web pages available 
on that server computer system or other server computer 
systems. Web pages may also be defined using other 
markup languages, including cHTML, XML, and XHTML. 
[0011] Every day, more and more information is made available 
via the Internet. The challenge posed to users is how to 
efficiently locate, access and use information and applica- 
tions that are relevant to them from amongst the huge 
quantities of materials that are available in a variety of 
different formats. For example, a user may wish to collect 
information from three different sources. Each of these 
sources may potentially maintain information in a differ- 
ent format. For instance, one source may be a database, a 
second may be a spreadsheet, and a third may be a Web 
page. 



[0012] One mechanism for providing access to personalized in- 
formation is a "portal". Corporate portals or enterprise in- 
formation portals (EIPs) have many uses and advantages, 
but the most common overarching task of any portal is to 
provide users with efficient access to personalized infor- 
mation and applications. For an internal network, this can 
mean employee information such as retirement account 
balances and vacation requests. It may also include sales 
force automation and enterprise resource planning (ERP) 
applications. Externally, portals can collect and make in- 
formation available to third parties such as business part- 
ners and customers. Portals can be used to simplify cus- 
tomer support, drive e-business, and/or accelerate con- 
tent distribution. 

[0013] A basic portal assembles static information in a single 
browser page for employee or customer use. Typically, 
static content is retrieved and placed into a giant reposi- 
tory which maintains all of the information used in the 
portal. The information is then reformatted and published 
to users of the portal. However managing a huge reposi- 
tory of content presents a number of difficulties to the or- 
ganization operating the portal. One problem is that some 
types of information must be constantly updated. For ex- 



ample, stock prices or weather reports change regularly 
and frequently. Another problem is operating the portal 
and managing the associated data typically requires a 
skilled technical team. 

[0014] Jo make portals more effective, organizations need to 

make their portals dynamic and flexible. A dynamic portal 
pulls updated information from company databases and 
other sources available through the Internet. For example, 
when a user goes to her home page, she wants to see the 
most recent headlines — not yesterday's news. A flexible 
portal is able to update information even if its content or 
location changes. In addition, organizations using portals 
try to make them sufficiently flexible so that they can be 
utilized to deliver information to new devices and new au- 
diences in new formats. 

[0015] There are a number of benefits that can be realized by en- 
suring that a portal is dynamic and flexible. Dynamic con- 
tent guarantees the site will remain fresh and relevant for 
employees and third parties (e.g., customers and business 
partners). Without updated content, audiences will likely 
go elsewhere for information, and a significant investment 
in implementing the portal will be wasted. In addition, dy- 
namic content makes the site more useful; keeping users 



on top of actionable information that can help them per- 
form various activities. 
[0016] A basic portal assembles static information in a single 
browser page for internal (e.g., employee) or external 
(e.g., customer) use. In order to provide increased rele- 
vance and flexibility what is needed is a solution that will 
automatically identify and gather information from many 
different sources (e.g., databases, flat files, documents, 
Web pages, and the like). The solution should combine 
this information to create portals that are dynamic and 
publish this information in real time. The solution should 
also enable information that is collected to be forwarded 
to other portals which can also modify their contents in 
real time, take action based on the information, and pro- 
cess the information (e.g., on a server or inside the user's 
browser) before presenting the information to the user. In 
addition, the solution should be easy to implement and 
should not require significant programming expertise or a 
huge repository for storing information that is collected. 
The present invention provides a solution for these and 
other needs. 
Summary of Invention 

[0017] An information messaging and collaboration system is 



described. In one embodiment, for example, a method of 
the present invention is described for interactive content 
retrieval and display, the method comprises steps of: pro- 
viding a plurality of portlets for retrieval of content for 
display in a user interface; mapping a message action to a 
first portlet to create a messaging portlet for sending a 
message in response to user interaction with the messag- 
ing portlet; creating a listener portlet by registering a sec- 
ond portlet to receive messages from the messaging port- 
let; and in response to user interaction with the messag- 
ing portlet, retrieving particular content for display in the 
user interface based on the message received by the lis- 
tener portlet from the messaging portlet. 
[0018] In another embodiment, for example, a system of the 

present invention is described for interactive content re- 
trieval and display, the system comprises: a user interface 
for display of content; an actioner module for display of 
content in the user interface and sending a message 
based on user interaction with the actioner module; a reg- 
istrar for receiving the message from the actioner module 
and routing the message to at least one listener module 
registered to receive the message; and at least one lis- 
tener module registered for receiving the message from 



the registrar and retrieving content for display in tlie user 
interface based on the message sent by the actioner mod- 
ule. 

[0019] In yet another embodiment, for example, a method of the 
present invention is described for collaborative retrieval 
and display of information in a Web page, the method 
comprises steps of: providing a plurality of elements for 
retrieval and display of information in a Web page; creat- 
ing a registrar for receiving a message and routing the 
message to at least one listening element registered to 
receive the message; associating a message action with a 
first element for sending a message in response to user 
interaction with the first element; registering at least one 
listener element with the registrar for receiving a message 
sent by the first element; and in response to user interac- 
tion with the first element, displaying particular informa- 
tion on the Web page based on the message received by 
the at least one listener element from the first element. 
Brief Description of Drawings 

[0020] Fig. 1 is a very general block diagram of a computer sys- 
tem (e.g., an IBM-compatible system) in which software- 
implemented processes of the present invention may be 
embodied. 



[0021] Fig. 2 is a block diagram of a software system for control- 
ling the operation of the computer system. 

[0022] Fig. 3A is a bitmap screenshot illustrating an appointment 
portlet that is captured from a calendar application. 

[0023] Fig. 3B is a bitmap screenshot illustrating an example 

messaging portlet (mPortlet) which is constructed in ac- 
cordance with the methodology of the present invention 
based on the appointment portlet of Fig. 3A. 

[0024] Fig. 3C is a bitmap screenshot illustrating a portlet that 
inserts/retrieves data from a database capture object 
when the user selects the "submit query" button. 

[0025] Fig. 3D is a bitmap screenshot illustrating an address 

mPortlet created based on mapping an action item to the 
portlet of Fig. 3C. 

[0026] Fig. 3E is a bitmap screenshot illustrating a sample map 
mPortlet which is generated as the result of a CGI post. 

[0027] Fig. 3F is a bitmap screenshot illustrating interactions be- 
tween a calendar mPortlet, an address mPortlet, and a 
map mPortlet. 

[0028] Fig. 4 illustrates an environment in which the system and 
methodology of the present invention may be imple- 
mented. 

[0029] Fig. 5A is a block diagram of a Web page in a browser 



window illustrating the structure of a Web page including 
four portlets in separate frames, and a masthead frame. 

[0030] Fig. 5B is a block diagram illustrating the same browser 

window previously depicted at Fig. 5A augmented to illus- 
trate the inclusion of messaging portlets. 

[0031] Fig. 6 is an example of a "click across" page containing 
the previously-described Symbol List, Address, and Map 
messaging portlets. 

[0032] Fig. 7 is a high-level flowchart illustrating the methods of 
operation of the system of the present invention in dy- 
namic collection and forwarding of information among 
messaging portlets enabling such mPortlets to process in- 
formation, modify their contents, and/or take action 
based on information received from another mPortlet. 

[0033] Fig. 8 is a diagram showing a "content container" divided 
into individual frames. 
Detailed Description 

Glossary 

[0034] The following definitions are offered for purposes of illus- 
tration, not limitation, in order to assist with understand- 
ing the discussion that follows. 

[0035] Bytecode: A virtual machine executes virtual machine low- 



level code instructions called bytecodes. Both the Sun Mi- 
crosystems Java virtual machine and the Microsoft .NET 
virtual machine provide a compiler to transform the re- 
spective source program (i.e., a Java program or a C# pro- 
gram, respectively) into virtual machine bytecodes. 

[0036] Document Object Model or DOM: The Document Object 
Model (DOM) is a platform- and language-neutral inter- 
face that allows programs and scripts to dynamically ac- 
cess and update the content, structure and style of docu- 
ments. The document can be further processed and the 
results of that processing can be incorporated back into 
the presented page. For further information regarding the 
Document Object Model, see e.g., "Document Object 
Model (DOM) Activity Statement" available from the World 
Wide Web consortium (W3C), the disclosure of which is 
hereby incorporated by reference. A copy of this docu- 
ment is available via the Internet (e.g., currently at 
www.w3.org/D0M). 

[0037] CGI: CGI is an abbreviation of Common Gateway Interface, 
a specification for transferring information between a 
World Wide Web server and a CGI program. A CGI program 
is any program designed to accept and return data that 
conforms to the CGI specification. CGI programs are a 



common way for Web servers to interact dynamically with 
users. Many HTML pages that contain forms, for example, 
use a CGI program to process the form's data once it is 
submitted. Another increasingly common way to provide 
dynamic feedback to Web users is to include scripts or 
programs that run on the user's machine rather than the 
Web server. These programs may comprise Java applets, 
Java scripts, or ActiveX controls. These technologies are 
known collectively as client-side solutions, while the use 
of CGI is a server-side solution because the processing 
occurs on the Web server. For further information regard- 
ing CGI see e.g., "CGI Specification, Version 1.1" available 
from the National Center for Supercomputing Applications 
(NCSA), the disclosure of which is hereby incorporated by 
reference. 

[0038] cHTML: Short for compact HTML, cHTML is a subset of 

HTML for small information devices, such as smart phones 
and PDAs. cHTML is essentially a pared down version of 
regular HTML. Because small devices such as cellular 
phones have hardware restrictions such as small memory, 
low power CPUs, limited or no storage capabilities, small 
mono-color display screens, single-character font and re- 
stricted input methods (the absence of a keyboard or a 



mouse), cHTML provides a simpler form of HT1\/IL for use 
with sucli devices. 

[0039] HTIVIL: HTIVIL stands for HyperText IVIarl<up Language, tlie 
autlioring language used to create documents on the 
World Wide Web. HTML defines the structure and layout of 
a Web document by using a variety of tags and attributes. 
For further description of HTML, see e.g., "HTML 4.01 
Specification", a World Wide Web consortium recommen- 
dation dated December 24, 1999, the disclosure of which 
is hereby incorporated by reference. A copy of this speci- 
fication is available via the Internet (e.g., currently at 
www.w3.org/TR/REC-html40). 

[0040] HTTP: HTTP is the acronym for HyperText Transfer Proto- 
col, which is the underlying communication protocol used 
by the World Wide Web on the Internet. HTTP defines how 
messages are formatted and transmitted, and what ac- 
tions Web servers and browsers should take in response 
to various commands. For example, when a user enters a 
URL in his or her browser, this actually sends an HTTP 
command to the Web server directing it to fetch and 
transmit the requested Web page. Further description of 
HTTP is available in "RFC 2616: Hypertext Transfer Proto- 
col — HTTP/1.1," the disclosure of which is hereby incor- 



porated by reference. RFC 2616 is available from the 
World Wide Web Consortium (W3C), and is available via 
the Internet (e.g., currently at www.w3.org/Protocols/). 
Additional description of HTTP is available in the technical 
and trade literature, see e.g., Stallings, W., "The Backbone 
of the Web," BYTE, October 1996, the disclosure of which 
is hereby incorporated by reference. 
[0041] Java: Java is a general purpose programming language de- 
veloped by Sun Microsystems. Java is an object-oriented 
language similar to C++, but simplified to eliminate lan- 
guage features that cause common programming errors. 
Java source code files (files with a .Java extension) are 
compiled into a format called bytecode (files with a .class 
extension), which can then be executed by a Java inter- 
preter. Compiled Java code can run on most computers 
because Java interpreters and runtime environments, 
known as Java virtual machines (VMs), exist for most op- 
erating systems, including UNIX, the Macintosh OS, and 
Windows. Bytecode can also be converted directly into 
machine language instructions by a Just-in-time (]\T) 
compiler. Further description of the Java Language envi- 
ronment can be found in the technical, trade, and patent 
literature; see e.g.. Gosling, J. et al., "The Java Language 



Environment: A White Paper," Sun Microsystems Computer 
Company, October 1995, the disclosure of which is hereby 
incorporated by reference. For additional information on 
the Java programming language (e.g., version 2), see e.g., 
"Java 2 SDK, Standard Edition Documentation, version 
1.4.2," from Sun Microsystems, the disclosure of which is 
hereby incorporated by reference. A copy of this docu- 
mentation is available via the Internet (e.g., currently at 
Java.sun.com/J2se/ 1. 4. 2/docs/index. html). 
[0042] JavaScript: JavaScript was designed by Netscape as an 
easy-to-use object-oriented scripting language that 
serves as an adjunct to the Java programming language. 
JavaScript is a small, lightweight language that is designed 
to be embedded in other products and applications, such 
as Web browsers. Inside a host environment, JavaScript 
can be connected to the objects of its environment to 
provide programmatic control over such objects. 
JavaScript code can be added to standard HTML pages to 
create interactive documents and has found considerable 
use in the creation of interactive Web-based forms. Most 
modern browsers, including those from Microsoft and 
Netscape, contain JavaScript support. For additional infor- 
mation on JavaScript, see e.g., "Core JavaScript Guide 1.5", 



from Netscape, the disclosure of which is hereby incorpo- 
rated by reference. A copy of this documentation is avail- 
able via the Internet (e.g., currently at 
devedge.netscape.com). 

[0043] Network: A network is a group of two or more systems 
linked together. There are many types of computer net- 
works, including local area networks (LANs), virtual private 
networks (VPNs), metropolitan area networks (IVIANs), 
campus area networks (CANs), and wide area networks 
(WANs) including the Internet. As used herein, the term 
"network" refers broadly to any group of two or more 
computer systems or devices that are linked together 
from time to time (or permanently). 

[0044] Portal: A portal provides an individualized or personalized 
view of multiple resources (e.g., Web sites) and services. A 
portal typically offers a single access point (e.g., browser 
page) providing access to a range of information and ap- 
plications. A portal assembles information from a number 
of different sources (e.g., Web sites and applications) en- 
abling a user to quickly receive information without hav- 
ing to navigate to a number of different Web sites. A por- 
tal also typically enables a user to obtain a personalized 
view of information and applications by organizing and 



grouping information and services for presentation to 
users. A portal may be considered to be composed of one 
or more portlets as defined below. 
[0045] Portlet: A portlet is an object that is responsible for cap- 
turing and delivering information to a portal from a spe- 
cific source. One or more individual portlets may then be 
organized on a Web page to create a portal for viewing by 
users using a browser. Information that may be captured 
by a portlet may include a Web page or portion of a Web 
page (e.g., collected from the World Wide Web), data re- 
trieved from a database, flat files (e.g., spreadsheet data 
and documents), and/or information collected from cus- 
tom interfaces to applications (e.g., information collected 
from an application via a Common Gateway Interface). For 
further information regarding portlets and portals, see 
e.g., "JSR168: Portlet Specification", the disclosure of 
which is hereby incorporated by reference. A copy of this 
specification is available via the Internet (e.g., currently at 
www.jcp.org). 

[0046] TCP: TCP stands for Transmission Control Protocol. TCP is 
one of the main protocols in TCP/IP networks. Whereas 
the IP protocol deals only with packets, TCP enables two 
hosts to establish a connection and exchange streams of 



data. TCP guarantees delivery of data and also guarantees 
that packets will be delivered in the same order in which 
they were sent. For an introduction to TCP, see e.g., "RFC 
793: Transmission Control Program DARPA Internet Pro- 
gram Protocol Specification", the disclosure of which is 
hereby incorporated by reference. A copy of RFC 793 is 
available via the Internet (e.g., currently at 
www.ietf.org/rfc/rfc793.txt). 

[0047] TCP/IP: TCP/IP stands for Transmission Control Protocol/ 
Internet Protocol, the suite of communications protocols 
used to connect hosts on the Internet. TCP/IP uses several 
protocols, the two main ones being TCP and IP. TCP/IP is 
built into the UNIX operating system and is used by the 
Internet, making it the de facto standard for transmitting 
data over networks. For an introduction to TCP/IP, see 
e.g., "RFC 1180: A TCP/IP Tutorial", the disclosure of 
which is hereby incorporated by reference. A copy of RFC 
1180 is available via the Internet (e.g., currently at 
www.ietf.org/rfc/rfcll80.txt). 

[0048] URL: URL is an abbreviation of Uniform Resource Locator, 
the global address of documents and other resources on 
the World Wide Web. The first part of the address indi- 
cates what protocol to use, and the second part specifies 



the IP address or the domain name where the resource is 
located. 

[0049] XHTML: Short for Extensible Hypertext Markup Language, 
a hybrid between HTML and XML XHTML is a family of 
current and future document types and modules that re- 
produce, subset, and extend HTML 4. XHTML family docu- 
ment types are XML based, and ultimately are designed to 
work in conjunction with XML-based user agents. 

[0050] XML: Short for Extensible Markup Language, a specifica- 
tion developed by the W3C. XML is a pared-down version 
of SGML, designed especially for Web documents. It allows 
designers to create their own customized tags, enabling 
the definition, transmission, validation, and interpretation 
of data between applications and between organizations. 
For further description of XML, see, e.g., Extensible 
Markup Language (XML) 1.0 specification which is avail- 
able from the World Wide Web Consortium (www.w3.org), 
the disclosure of which is hereby incorporated by refer- 
ence. The specification is also available on the Internet 
(e.g., currently at www.w3.org/TR/REC-xml). 
Introduction 

[0051] Referring to the figures, exemplary embodiments of the 
invention will now be described. The following description 



will focus on the presently preferred embodiment of the 
present invention, which is implemented in desktop and/ 
or server software (e.g., driver, application, or the like) 
operating in an Internet-connected environment running 
under an operating system, such as the Microsoft Win- 
dows operating system. The present invention, however, 
is not limited to any one particular application or any par- 
ticular environment. Instead, those skilled in the art will 
find that the system and methods of the present invention 
may be advantageously embodied on a variety of different 
platforms, including Macintosh, Linux, Solaris, UNIX, 
FreeBSD, and the like. Therefore, the description of the 
exemplary embodiments that follows is for purposes of il- 
lustration and not limitation. The exemplary embodiments 
are primarily described with reference to block diagrams 
or flowcharts. As to the flowcharts, each block within the 
flowcharts represents both a method step and an appara- 
tus element for performing the method step. Depending 
upon the implementation, the corresponding apparatus 
element may be configured in hardware, software, 
firmware or combinations thereof. 
Computer-based implementation 

[0052] system hardware (e.g., for desktop and server computers) 



[0053] The present invention may be implemented on a conven- 
tional or general-purpose computer system, such as an 
IBM-compatible personal computer (PC), a laptop com- 
puter, a notebook computer, a handheld or pocket com- 
puter, and/or a server computer. Fig. 1 is a very general 
block diagram of a computer system (e.g., an IBM- 
compatible system) in which software-implemented pro- 
cesses of the present invention may be embodied. As 
shown, system 100 comprises a central processing unit(s) 
(CPU) or processor(s) 101 coupled to a random-access 
memory (RAM) 102, a read-only memory (ROM) 103, a 
keyboard 106, a printer 107, a pointing device 108, a dis- 
play or video adapter 104 connected to a display device 
105, a removable (mass) storage device 115 (e.g., floppy 
disk, CD-ROM, CD-R, CD-RW, DVD, or the like), a fixed 
(mass) storage device 116 (e.g., hard disk), a communica- 
tion (COMM) port(s) or interface(s) 110, a modem 112, 
and a network interface card (NIC) or controller 111 (e.g., 
Ethernet). Although not shown separately, a real time sys- 
tem clock is included with the system 100, in a conven- 
tional manner. 

[0054] CPU 101 comprises a processor of the Intel Pentium family 
of microprocessors. However, any other suitable proces- 



sor may be utilized for implementing the present inven- 
tion. The CPU 101 communicates with other components 
of the system via a bi-directional system bus (including 
any necessary input/output (I/O) controller circuitry and 
other "glue" logic). The bus, which includes address lines 
for addressing system memory, provides data transfer be- 
tween and among the various components. Description of 
Pentium-class microprocessors and their instruction set, 
bus architecture, and control lines is available from Intel 
Corporation of Santa Clara, CA. Random-access memory 
102 serves as the working memory for the CPU 101. In a 
typical configuration, RAM of sixty-four megabytes or 
more is employed. More or less memory may be used 
without departing from the scope of the present inven- 
tion. The read-only memory (ROM) 103 contains the basic 
input/output system code (BIOS) — a set of low-level rou- 
tines in the ROM that application programs and the oper- 
ating systems can use to interact with the hardware, in- 
cluding reading characters from the keyboard, outputting 
characters to printers, and so forth. 
[0055] Mass storage devices 115, 116 provide persistent storage 
on fixed and removable media, such as magnetic, optical 
or magnetic-optical storage systems, flash memory, or 



any other available mass storage technology. The mass 
storage may be shared on a network, or it may be a dedi- 
cated mass storage. As shown in Fig. 1, fixed storage 116 
stores a body of program and data for directing operation 
of the computer system, including an operating system, 
user application programs, driver and other support files, 
as well as other data files of all sorts. Typically, the fixed 
storage 116 serves as the main hard disk for the system. 
[0056] In basic operation, program logic (including that which 
implements methodology of the present invention de- 
scribed below) is loaded from the removable storage 115 
or fixed storage 116 into the main (RAM) memory 102, for 
execution by the CPU 101. During operation of the pro- 
gram logic, the system 100 accepts user input from a 
keyboard 106 and pointing device 108, as well as speech- 
based input from a voice recognition system (not shown). 
The keyboard 106 permits selection of application pro- 
grams, entry of keyboard-based input or data, and selec- 
tion and manipulation of individual data objects displayed 
on the screen or display device 105. Likewise, the pointing 
device 108, such as a mouse, track ball, pen device, or the 
like, permits selection and manipulation of objects on the 
display device. In this manner, these input devices sup- 



port manual user input for any process running on the 
system. 

[0057] The computer system 100 displays text and/or graphic 
images and other data on the display device 105. The 
video adapter 104, which is interposed between the dis- 
play 105 and the system's bus, drives the display device 
105. The video adapter 104, which includes video memory 
accessible to the CPU 101, provides circuitry that converts 
pixel data stored in the video memory to a raster signal 
suitable for use by a cathode ray tube (CRT) raster or liq- 
uid crystal display (LCD) monitor. A hard copy of the dis- 
played information, or other information within the sys- 
tem 100, may be obtained from the printer 107, or other 
output device. Printer 107 may include, for instance, an 
HP LaserJet printer (available from Hewlett Packard of Palo 
Alto, CA), for creating hard copy images of output of the 
system. 

[0058] The system itself communicates with other devices (e.g., 
other computers) via the network interface card (NIC) 111 
connected to a network (e.g., Ethernet network, Bluetooth 
wireless network, or the like), and/or modem 112 (e.g., 
56K baud, ISDN, DSL, or cable modem), examples of 
which are available from 3Com of Santa Clara, CA. The 



system 100 may also communicate with local occasion- 
ally-connected devices (e.g., serial cable-linked devices) 
via the communication (COMM) interface 110, which may 
include a RS-232 serial port, a Universal Serial Bus (USB) 
interface, or the like. Devices that will be commonly con- 
nected locally to the interface 110 include laptop comput- 
ers, handheld organizers, digital cameras, and the like. 

[0059] IBM-compatible personal computers, laptop computers, 
notebook computers, handheld computers, and server 
computers are available from a variety of vendors. Repre- 
sentative vendors include Dell Computers of Round Rock, 
TX, Hewlett-Packard of Palo Alto, CA, and IBM of Armonk, 
NY. Other suitable computers include Apple-compatible 
computers (e.g., Macintosh), which are available from Ap- 
ple Computer of Cupertino, CA, and Sun Solaris worksta- 
tions, which are available from Sun Microsystems of 
Mountain View, CA. 

[0060] Basic system software 

[0061] Fig. 2 is a block diagram of a software system for control- 
ling the operation of the computer system 100. As shown, 
a computer software system 200 is provided for directing 
the operation of the computer system 100. Software sys- 
tem 200, which is stored in system memory (RAM) 102 



and on fixed storage (e.g., hard disk) 116, includes a Icer- 
nel or operating system (OS) 210. Tlie OS 210 manages 
low-level aspects of computer operation, including man- 
aging execution of processes, memory allocation, file in- 
put and output (I/O), and device I/O. One or more appli- 
cation programs, such as client application software or 
"programs" 201 (e.g., 201a, 201b, 201c, 201d) may be 
"loaded" (i.e., transferred from fixed storage 116 into 
memory 102) for execution by the system 100. The appli- 
cations or other software intended for use on the com- 
puter system 100 may also be stored as a set of down- 
loadable computer-executable instructions, for example, 
for downloading and installation from an Internet location 
(e.g., Web server). 
[0062] Software system 200 includes a graphical user interface 
(GUI) 215, for receiving user commands and data in a 
graphical (e.g., "point-and-click") fashion. These inputs, 
in turn, may be acted upon by the system 100 in accor- 
dance with instructions from operating system 210, and/ 
or client application module(s) 201. The GUI 215 also 
serves to display the results of operation from the OS 210 
and application(s) 201, whereupon the user may supply 
additional inputs or terminate the session. Typically, the 



OS 210 operates in conjunction with device drivers 220 
(e.g., "Winsocl<" driver — Windows' implementation of a 
TCP/IP stack) and the system BIOS microcode 230 (i.e., 
ROM-based microcode), particularly when interfacing with 
peripheral devices. OS 210 can be provided by a conven- 
tional operating system, such as Microsoft Windows 9x, 
Microsoft Windows NT, Microsoft Windows 2000, or Mi- 
crosoft Windows XP, all available from Microsoft Corpora- 
tion of Redmond, WA. Alternatively, OS 210 can also be an 
alternative operating system, such as the previously men- 
tioned operating systems. 
[0063] The above-described computer hardware and software are 
presented for purposes of illustrating the basic underlying 
desktop and server computer components that may be 
employed for implementing the present invention. For 
purposes of discussion, the following description will 
present examples in which it will be assumed that there 
exists a "server" (e.g., Web server) that communicates with 
one or more "clients" (e.g., desktop computers, laptop 
computers, notebook computers, handheld computers, 
"smart phones", personal digital assistants (PDAs), and/or 
other computing devices). The following discussion also 
uses examples of Web pages implemented using HTML; 



however, the present invention may also be used in con- 
junction with Web pages written in various other marl<up 
languages, including, but not limited to, cHTML, XML, and 
XHTML The present invention, however, is not limited to 
any particular environment or device configuration. In 
particular, a client/server distinction is not necessary to 
the invention, but is used to provide a framework for dis- 
cussion. Instead, the present invention may be imple- 
mented in any type of system architecture or processing 
environment capable of supporting the methodologies of 
the present invention presented in detail below. 
Overview 

[0064] A basic portal assembles static information in a single 

browser page (e.g., for use by employees or customers of 
an organization). To make portals more effective, organi- 
zations need to make their portals dynamic and flexible 
so that they are capable of collecting information from a 
variety of sources and updating the information even if its 
content or location changes from time to time. Dynamic 
content ensures that the site using the portal will remain 
fresh and relevant for employees and customers. Without 
updated content, audiences will go elsewhere for informa- 
tion, and the investment in the portal may be wasted, in 



addition, dynamic content mal<es the site more useful, 
l<eeping users on top of actionable information. 

[0065] In discussing the use of dynamic content, one may think 
of a portal as comprised of individual "portlets", each of 
which in responsible for capturing and delivering informa- 
tion to the portal (e.g., a Web page) from a specific 
source. Examples of portlets include: 

[0066] Static & dynamic HTML - a Web page or portion of a Web 
page collected from the World Wide Web. 

[0067] Database content - data retrieved from a database. 

[0068] Flat File - spreadsheet data and documents (e.g., Adobe 
PDF files). 

[0069] Custom Interfaces to Legacy Web Applications - informa- 
tion collected from any accessible API (e.g., a Common 
Gateway Interface). 

[0070] Individual portlets may then be laid out on a Web page to 
create a portal. Thus, the task of building and maintaining 
a portal is, in many ways, essentially the task of building 
and maintaining individual portlets and coordinating their 
display. 

[0071] The present invention introduces the concept of a "mes- 
saging portlet" or "mPortlet" for collecting and combining 
information from a number of different sources in a man- 



ner which provides real-time, interactive (i.e., user driven) 
content aggregation. A "messaging portlet" or "mPortlet" 
can be defined as a portlet that participates in sharing in- 
formation between itself and other messaging portlets 
(mPortlets). Distinct and independent portlets have no 
knowledge of each other, their parameter requirements, 
and their subsequent actions. Messaging portlets are de- 
signed to be "autonomous" from other messaging 
portlets, from the hosting application server, and from the 
container in which they are enclosed. A messaging portlet 
can be viewed as an object with well defined messages 
that are "broadcast" to other mPortlet (and mContainer) 
objects that are "listening" for specific message content. 
Using well-defined message definitions, the mPortlets are 
"reusable" objects that can participate intelligently in 
combination with other mPortlets to form more dynamic 
and flexible portals and to establish a new form of Web 
application. 

[0072] Information from many different sources can be used to 
create a messaging portlet (mPortlet). A messaging portlet 
can also be combined with other mPortlets to create an 
integrated Web based application. In addition, a "messag- 
ing container" or "mContainer" can be built based on sev- 



eral mPortlets. The use of messaging portlets created in 
accordance witli tlie present invention provides a new type 
of Web application or service that can provide users with a 
powerful mechanism for developing new business process 
and analysis techniques. One advantage of this architec- 
ture is that a messaging container including several 
mPortlets can be deployed on any "common" Web server, 
and be viewed from any common browser. No operating 
system or browser specific code is required for implemen- 
tation of these mContainers. Messaging containers can 
also be used within any existing content management 
system. These features make it easy for users to adopt, 
deploy, and utilize this technology. 
[0073] It should be noted that there are a number of other widely 
used terms that are generally related to (but should be 
distinguished from) the messaging portlet concept. The 
terms "cooperative portlets" or "collaborative portlets" 
have been used to describe related (but different) con- 
cepts. The use of the term "collaborative portlets", in par- 
ticular, has been associated with the ability to include user 
or group collaboration-type functions in a portal. This 
definition is somewhat confusing since it crosses the defi- 
nition of a portlet that includes user or group collabora- 



live functions with a portlet that can "communicate" with 
other portlets. The definition and implementation of the 
messaging portlets (mPortlets) of the present invention as 
described in this document is not limited to portlets that 
provide user or group collaboration-type functions, but 
rather extends as well to other types of portlets providing 
other functions. 
[0074] jhe present invention combines the use of messaging 
portlets with an innovative user interface that makes the 
solution easy to implement and use. A user without ex- 
tensive technical skills or training can use the solution for 
identifying, extracting, and retrieving information in a 
number of situations that previously required complex 
development tasks. The system and methodology of the 
present invention for information messaging and collabo- 
ration will now be described in more detail. 
Example of Operations 

[0075] Creation of messaging portlets 

[0076] Fig. 3A illustrates a standard appointment portlet 310 that 
is captured from a calendar application. As shown, Fig. 3A 
shows five appointments 311, 312, 313, 314, and 315 
(each identified by a bullet point and a company name) on 



July 27, 2001. Each appointment is a HTML anchor. In the 
example illustrated at Fig. 3A, the user may wish to click 
on any of the five appointment anchors 311-315 (i.e., 
company names) in order to drill down into details about 
the given appointment. 

[0077] Fig. 3B illustrates an example messaging portlet (mPortlet) 
320 which is constructed in accordance with the method- 
ology of the present invention based on the appointment 
portlet of Fig. 3A. As shown, five action icons 321, 322, 
323, 324, and 325 have been added to the standard ap- 
pointment portlet, with one icon added after each of the 
five appointment anchors 311-315 (company names). 

[0078] The process of creating a calendar messaging portlet 

(e.g., mPortlet 320) from the standard portlet of Fig. 3A 
includes performing a "mapping" operation in which the 
user can select the type of content they wish to map to a 
message. "Mapping" is the process of matching a user as- 
signed label to anchors, input forms, CGI parameters and 
other "information landmarks" such as SQL database 
queries and Excel spreadsheet objects. Using "feature ex- 
traction" methodology of the present invention, a signa- 
ture or "Web fingerprint" of each item of information (or 
"information atom") in the portlet is created. The user can 



then "map" portlet contents to actions. In the example il- 
lustrated at Fig. 3B, the user may wish to click on any of 
the five appointment anchors 311-315 (i.e., company 
names) and still have the calendar mPortlet 320 operate in 
the same manner as with the static portlet 310 of Fig. 3A 
(e.g., to provide further detail about each of the appoint- 
ments). 

[0079] As the appointment anchors are mapped, "action icons" 

321-325 are added after each of the five appointment an- 
chors 311-315 as shown at Fig. 3B. When selected (e.g., 
clicked on) these action icons, may, for example, broad- 
cast a message containing the visible text of the anchor 
which is then displayed to the user. It should be noted 
that the action icon is only one example of a mechanism 
that can be used to initiate action. Various different icons 
or other methods may be used to enable a user to initiate 
actions from a given messaging portlet or container. Also, 
different types of action icons can be used within a mes- 
saging portlet. For example, one can have a message with 
a name "Company Name" with an icon of a building. If the 
messaging portlet also includes anchors that are stock 
symbols, they could be assigned a different action icon. In 
the currently preferred embodiment, the mPortlet objects 



that share the same feature extraction tag generally have 
the same action icon (i.e., an icon with a similar appear- 
ance) and the same message name (i.e., the message 
name must be unique to the mPortlet). Every different "fea- 
ture tag" on a Web page can be mapped to send a differ- 
ent message. The message can be an identifier, the an- 
chor's visible text, the anchor's original HREF (an attribute 
indicating the URL to be loaded when a hyperlinked object 
is activated), or any other information contained in the 
anchor tag. 

[0080] Mapping is performed in a similar manner to that used for 
HTML forms. Fig. 3C illustrates a simple portlet 330 that 
inserts/retrieves data from a database capture object 
when the user selects the "submit query" button 331. Fig. 
3D illustrates an address mPortlet 340 created based on 
mapping an action item to the simple portlet 330 of Fig. 
3C. When the form is mapped, the designer can replace 
the POST attribute of the form (data capture object) with a 
JavaScript broadcast message. As shown at Fig. 3D, in this 
example an "action icon" 343 is added next to the "submit 
query" button 341. If the user clicks on the "submit query" 
button 341, the form will operate exactly as it would if no 
"interactive" objects (i.e., action icons) were added to it. 



However, clicking on the action icon 343 causes tlie con- 
tents to be broadcast to other mPortlets (not shown at Fig. 
3D) listening to receive the information. In the currently 
preferred embodiment, these other "mPortlet" listeners 
will not receive messages if the user clicks on the "submit 
query" button 341. 

[0081] In a situation in which a given messaging portlet captures 
the result of a Common Gateway Interface (CGI) post, the 
actual CGI parameters can be replaced with information 
received from other mPortlets. For example, Fig. 3E illus- 
trates a sample map mPortlet 350 which is generated as 
the result of a CGI post. When the mPortlet 350 shown at 
Fig. 3E is built it is configured to "listen" for messages 
containing parameters it needs to complete the CGI pa- 
rameter list. In this example the mPortlet 350 does not 
have any associated "action icons". Instead, the mPortlet 
350 shown at Fig. 3E is a pure "listener" that waits for 
messages from other mPortlets (e.g., mPortlet 340) before 
posting the parameters to the host MapQuest application. 
For instance, address information sent by another mPort- 
let may cause mPortlet 350 to display a map that depicts 
the location of the given address. 

[0082] Fig. 3F illustrates interactions between the calendar 



mPortlet 320, the address mPortlet 340, and the map 
mPortlet 350. The interactive nature of these three mes- 
saging portlets enables a user to check his calendar for a 
given day in calendar mPortlet 320. The user may then 
click on the "anchor" of a given appointment (e.g., ap- 
pointment anchor 311) to drill down into the information 
or click on the "action icon" 321 associated with this ap- 
pointment to send the information to the address mPortlet 
340. If the user elects to click on the action icon 312 next 
to the appointment anchor 311, a message is sent to the 
associated address mPortlet 340. The address mPortlet 
340 uses the name of the company (IBM in this example) 
received from the calendar mPortlet 320 to query a 
database server and fill in the form to display the address 
of the company. 

[0083] The user can then send the form's information to the host 
using the Submit Query button 341 or select the action 
icon 343 to send the information to the map mPortlet 350 
which is waiting for the information necessary to complete 
a CGI POST to a MapQuest host application. The address 
information sent to the map mPortlet 350 causes a map 
centered on the company address to be displayed to the 
user in a browser interface. 



[0084] Methods of interacting with messaging portlet 

[0085] In the currently preferred embodiment, there are several 
different ways a user can interact with portlets and mes- 
saging portlets (mPortlets), including the following: 

[0086] Click-Thru: Click-Thru refers to the act of refreshing the 
same portlet with the action of a link or a HTML form In 
that portlet. This Is commonly used In a portlet containing 
Java Server Page QSP) elements. Portlets containing JSP el- 
ements generally contain actions that change the display 
dependent on user data entry. This Is also sometimes re- 
ferred to as "Inline click-thru". 

[0087] Click-Out: Click-Out refers to the action of opening a new 
browser window that contains the action of a link or a 
HTML form In the original portlet. This Is commonly used 
by portlets containing Web elements to provide for the 
whole page of the link's action to be displayed In a new 
browser window. 

[0088] Click-Across: Click-Across Is a new term introduced by 
the implementation of messaging portlets (mPortlets) re- 
ferring to the act of refreshing a related portlet's or 
mPortlet's window content based on the original mPort- 
let's action or contents. This Is an Important feature of a 
messaging portlet and may be used In conjunction with 



mPortlets containing all types of elements (e.g., Java 
server pages, Web, HTML, Java, XML, XHTML, cHTML, Web 
services, etc.). 

[0089] In the example shown at Fig. 3F, the calendar mPortlet 

320, the address mPortlet 340, and the map mPortlet 350 
may send messages to each other and to the server. This 
example illustrates how three messaging portlets can 
work together to form a very simple Web application made 
from components pulled from different sources and tech- 
nologies. Messaging portlets can also be bundled together 
into a group that can be combined as building blocks with 
other Web applications to produce more powerful and 
complex applications. 

[0090] Building Web applications using mPortlets and mContainers 

[0091] The basic building blocks for powerful Web applications 
that use the messaging portlets of the present invention 
as the smallest element are referred to herein as "messag- 
ing containers" or "mContainers". As previously described, 
a "messaging container" or "mContainer" is an object that 
contains one or more messaging portlets (mPortlets). The 
messaging containers (mContainers) can be used in sev- 
eral different ways. Messaging containers can be executed 
on a server to combine several processes to produce a 



portlet view that will be displayed on the client. Messaging 
containers can also be used to communicate with other 
mContainers in the same manner that mPortlets commu- 
nicate with each other. In addition, mContainers can be 
used within other content management systems to pro- 
vide mPortlet functionality in systems designed for static 
HTML portlets. Off-screen mContainers can be scheduled 
(e.g., using an "agent" or manager component) to collect 
content and cache the new mPortlet in the Web applica- 
tion's "ready cache" for quick rendering. A messaging 
container located on a server can be called from a mes- 
saging portlet so that aggregation of data is performed on 
the server and the aggregated results returned to the re- 
questing mPortlet. In addition, a Web application can be 
built using several mContainers, each sending messages 
to other mContainers. Significantly, complex program- 
ming is not required in order to use mPortlets and mCon- 
tainers to build powerful Web applications. 
[0092] Popular Web applications place an emphasis on "Web 
transactions" in which a page request is received and a 
page is returned from a database definition or a HTML 
static file. Real-time content collection, aggregation, and 
especially "interactive" Web applications require a Web ap- 



plication architecture that has all of the advantages of a 
content management system (CMS) for delivering the 
mContainer definition, but is scalable enough to handle 
CPU-intensive requests, such as a request to find a single 
object within a page of objects. The mPortlets and mCon- 
tainers of the present invention are very scalable as all of 
the message maps are downloaded to the client with each 
mPortlet so that all messaging can be handled by the 
client. An environment in which the system of the present 
invention may be preferably implemented will now be de- 
scribed. 
System components 

[0093] Fig. 4 illustrates an environment 400 in which the system 
and methodology of the present invention may be imple- 
mented. As shown at Fig. 4, environment 400 includes 
one or more content appliance server(s) 410, a Web appli- 
cation 420 running on a Web server 430, and a client 450 
connected to the Web application 420 on the Web server 
430 via the Internet 440. As also shown, a messaging 
container (mContainer) 460 including three messaging 
portlets (mPortlets) 461, 462, and 463 is in operation on 
the client 450. Although a single client is shown at Fig. 4 
for illustration, a typical environment will include a plural- 



ity of clients 450 connected to the Web application 420. 
Each of these components and their operations are de- 
scribed below in more detail. 
[0094] jhe content appliance server(s) 410 identify, capture, and 
retrieve items of content. In the currently preferred em- 
bodiment, specialized content appliance servers are em- 
ployed which are built from a tuned Linux kernel and con- 
figured to efficiently perform the task of retrieving con- 
tent (e.g., from the World Wide Web). Further description 
of a system providing methods for dynamic capture and 
retrieval of content is provided in commonly-owned, co- 
pending U.S. patent application Serial No. 09/780,993 ti- 
tled "System and Method for Dynamic Content Retrieval", 
the disclosure of which is hereby incorporated by refer- 
ence. As capture requests increase with the number of 
users, additional content appliance servers 410 can are 
added to the cluster shown at Fig. 4. Load balancing soft- 
ware or hardware, such as the Cisco LoadDirector, can be 
used for load balancing of content appliance servers in 
the cluster. 

[0095] The Web application 420 is an Internet-enabled applica- 
tion that is operating on a Web server 430. The Web ap- 
plication 420 includes one or more messaging portlets 



and/or messaging containers created in accordance with 
tlie metliodology of tlie present invention. Typically, a 
user (e.g., a developer, content manager, or other "knowl- 
edge worker") creates one or more mPortlets using the 
system and methodology of the present invention. For ex- 
ample, the user may create the three mPortlets 461, 462, 
463 shown at Fig. 4. A messaging container is then typi- 
cally created as a container for the mPortlets. In this ex- 
ample, the mContainer 460 is created and the mPortlets 
461, 462, 463 are included in the mContainer 460. The 
mContainer 460 is then published through the Web appli- 
cation 420 (e.g., a PlumTree Web application or BEA Per- 
sonalization Server application). The mContainer 460 be- 
ing displayed within the Web application 420 does not re- 
quire any change to the hosting server's implementation. 
Messaging within the mContainer is handled by the 
browser on the client device 450, and refreshing of con- 
tent is handled by requests from each mPortlet (i.e., 
mPortlets 461, 462, 463) to the content appliance 
server(s) 410. 

[0096] As shown at Fig. 4, the client 450 accesses and loads the 
mContainer 460 that has been published by the Web ap- 
plication 420 on the Web server 430. On the client 450, 



each of the mPortlets (i.e., mPortlets 461, 462, 463) in the 
mContainer 460 refreshes itself by making a request to 
the content appliance server(s) 410 as shown at Fig. 4. In 
response to a user of the client device 450 entering data, 
or clicking on (i.e., selecting) different action icons, a 
message may be sent to other mPortlets. Each of the 
mPortlets also refreshes itself by making a request to the 
content appliance server(s) 410. 
[0097] The mContainer(s) 460 and mPortlets 461, 462, 463 can 
be exported and run within a number of different content 
management systems (e.g., BEA and PlumTree content 
management systems) by appearing to be a standard 
HTML portlet or object. In addition, a messaging container 
(e.g., mContainer 460 as shown at Fig. 4) can look like a 
standard HTML portlet while still providing a messaging 
environment for its enclosed mPortlets (e.g., mPortlets 
461, 462, 463). Each of the mPortlets is an autonomous 
object designed to be reusable. A messaging portlet is 
autonomous in that it does not know who is sending or 
receiving any message, it only knows about itself, not its 
neighbors or its parents. Inter-portlet messaging is han- 
dled by the browser without requiring Web application 
host interaction. 



[0098] Messaging containers (mContainers) can communicate 
witli otiier mContainers to produce complex but scalable 
Web applications drawing content in real-time from the 
Web, databases, flat files, and legacy Web applications. 
These mContainers can run on a client browser or be 
scheduled to run on the server by "agent" components. 
Also, mContainers can start on a client device, with mes- 
sages sent to an "off screen" mContainer that will produce 
new content and send this new content directly to the 
user's browser on the client device. Offscreen mContain- 
ers can also be scheduled by an "agent" (or manager) to 
collect content and cache the new mPortlet in a "ready 
cache" of a Web application for quick rendering as previ- 
ously described. 
Implementation of messaging portlets 

[0099] Browser frame organization 

[0100] In the currently preferred embodiment of the present in- 
vention, portlets on a page are organized and imple- 
mented as separate HTML inline frames to facilitate inde- 
pendent loading. Each HTML inline frame operates as a 
separate portlet. 

[0101] One of the options for representing a portlet is to repre- 



sent the portlet as a HTML inline frame, using the HTIVIL 
IFRAIVIE tag. An inline frame (floating frame) is a construct 
which embeds a document into a HTML document so that 
embedded data is displayed inside a sub-window of the 
browser's window. This does not mean full inclusion; the 
two documents are independent, and both them are 
treated as complete documents, instead of treating one as 
part of the other. Most, but not all, browsers support this 
inline frame HTML tag. (Note that the IFRAME tag is de- 
scribed in the HTML 4.0 reference, but is not defined as a 
strict tag.) Using inline frames to represent portlets is 
useful since all the frames are accessible from the 
browser's Document Object Model (DOM). This allows 
JavaScript to be used to manipulate contents and actions 
of each and every inline frame in a browser window 
(subject to security constraints of the browser and the 
contents of the frame). 
[0102] vVeb pages that contain inline frames have a known hier- 
archy of frame organization. Each inline frame, or child 
frame, can reference its parent frame directly in its own 
JavaScript, using the parent object. Likewise, the parent 
frame's JavaScript can reference the contents of the Docu- 
ment Object Model (DOM) within a child frame. Fig. 5A is a 



block diagram of a Web page in a browser window illus- 
trating the structure of a Web page including four portlets 
in separate frames 511, 512, 513, 514 and a masthead 
frame 517. Frames can be embedded within other frames 
to create additional levels of hierarchy. As shown, a sub- 
frame 519 is embedded in frame 514. However, refer- 
ences to each frame's "parent" object in turn will eventu- 
ally give a reference to the outermost browser window, 
the top level frame 510 as illustrated at Fig. 5A. 
[01 03] Listeners and actioners 

[0104] Messaging portlets have been designed so that there are 
no dependencies between individual mPortlets. When 
portlets are designated as messaging portlets they con- 
tinue to operate in the same manner as they would if they 
were not designated as messaging portlets. In object ori- 
ented programming parlance, messaging portlets must be 
decoupled from each other while continuing to provide 
inter-portlet communication. This is a powerful feature 
because it allows mPortlets to be added to a page based 
on user choice and personalization rather than forcing the 
user to use a fixed set of tightly coupled portlets. 

[0105] This decoupling of mPortlets is achieved by utilizing a 

central registration point for all mPortlets. In the currently 



preferred embodiment, the topmost browser window (as 
sliown at Fig. 5A) is used as this central registration point 
as the topmost browser window is a part of the Web page 
that is guaranteed to be always available, populated and 
accessible. Also a distinction must now be made between 
the different functions in messaging portlets. When an 
mPortlet is expected to receive information that it is to 
then process, it is called a listener. When an mPortlet is 
expected to send information to be processed by other 
mPortlets, it is called an actioner. Since listeners are the 
targets, they must register with a central controller, or 
registrar. The registrar is not a type of messaging portlet; 
rather, it is a central function that ties together messaging 
portlets. Fig. 5B illustrates the same browser window pre- 
viously depicted at Fig. 5A augmented to illustrate the in- 
clusion of messaging portlets. The items added to the 
browser window include a registrar 521, an actioner 531 
and two listeners 534 and 536. As shown at Fig. 5B, the 
registrar is in the top-level window, while the actioner 
531 is in frame 511, the first listener 534 is in frame 512, 
and the second listener 536 is in frame 513. 
[0106] When the registrar 521 receives a notification from an ac- 
tioner (e.g., actioner 531), it looks up the registered lis- 



teners (e.g., listeners 534, 536) and notifies eacli of tliem 
in turn. Tliere is no necessity to register actioners witli tlie 
registrar, since an actioner is not tlie target for tlie action 
it provides. However, it may be possible that an actioner is 
also listener for other pieces of information. 

[0107] It should be noted that the registrar 521 does not directly 
affect the contents of the target portlets. Instead, the reg- 
istrar passes a notification into the listener frame of the 
target. This is an important consideration that is neces- 
sary to cleanly decouple portlets. The registrar's job is 
only to register and notify. The actioner is responsible for 
packaging up the notification data and passing the notifi- 
cation event to the registrar. It is the responsibility of the 
listener to register and then process the notification. 

[0108] In the currently preferred embodiment, the binding of a 
notification event to a listener's registration is done using 
a string value. When a listener registers with the registrar, 
the listener identifies a string value. When an actioner no- 
tifies the registrar it uses a string value. The string value 
is used to check each registration. The string value pro- 
vided by the actioner is compared to the value of regis- 
tered listeners. If the value matches a registered listener, 
then that listener is notified. There may be multiple regis- 



trations for each frame; however, each registration is gen- 
erally associated with a different registration string value. 

[0 1 09] JavaScript functions 

[0^^0] in the presently preferred embodiment, the implementa- 
tion of the registrars, the actioners, and the listeners re- 
lies on the use of generalized JavaScript code. To keep the 
design as simple and elegant as possible, the same set of 
JavaScript functions are declared in the topmost window 
and also used for the registrar as well as for the actioners 
and listeners in the messaging portlets. The following dis- 
cussion assumes that the target of a notification is a 
HTML FORM text field. This is consistent with how the 
system of the currently preferred embodiment represents 
portlet parameters to the user. 

[Oil"'] The following are the public function declarations in the 
JavaScript of the currently preferred embodiment: 

[0112] Register(targetframe, form, parameter, registeras): The 
"Register" function is used by a listener to register itself. 
The "targetframe" is used by the registrar when it needs to 
pass notifications to this frame. The "form" and "parame- 
ter" values identify a HTML FORM field that is the target 
for the data involved in the notification. The "registeras" 
field is the unique string against which this registration is 



associated. 

[0113] UnRegister(targetframe, form, parameter, registeras): The 
"UnRegister" function is used by listeners to delete a pre- 
viously made registration. This provides the opportunity 
for a frame to optionally turn on and off its ability to re- 
ceive notifications from the registrar. 

[0114] Notify(srcframe, notifyas, value) and NotifyAII(srcframe, 
notifyas, value): The "Notify" and "NotifyAII" functions are 
used by actioners to initiate a notification event. The "sr- 
cframe" value is not used by the registrar, but included for 
completeness. The "notifyas" value is used by the registrar 
to compare against the "registeredas" values for each reg- 
istered listener. The value is the data associated with the 
notification. The difference between the Notify and the 
NotifyAII functions is that the Notify function will pass the 
notification only to the first registered listener associated 
with the "notifyas" value (i.e., the order of registrations is 
not guaranteed). The NotifyAII function passes the notifi- 
cation to all registered listeners associated with the "noti- 
fyas" function. 

[0115] NotifyThis(form, parameter, value): The "NotifyThis" func- 
tion is used by the registrar when a match is made be- 
tween a notification and a listener. In the current imple- 



mentation the target is assumed to be a HTML FORM field, 
tliat is a text field or a hidden field. 

[0116] A local variable is used to differentiate between the regis- 
trar and the inner frames in the presently preferred em- 
bodiment. Although the same variable is declared in mul- 
tiple places within the JavaScript, the inner frame declara- 
tions over-ride the topmost declaration for the scope of 
that frame, thus ensuring calls in the frame are performed 
correctly. To ensure that frame hierarchy is always main- 
tained (even for inner frames, and sub-frames of inner 
frames, and so forth) the function is only executed when 
the local variable indicates it is the top-most frame. Oth- 
erwise, it passes the execution to the equivalent function 
of its parent(s). For example, the "Register" function con- 
tains the following code segment: 

[0117] 1: if (lamTopFrameset) { 

2 : parent.Register(targetframe,form,parameter,registeras 

); 

3:} 
4: ... 

[0118] Similarly, the "NotifyAII" function contains the following 
code segment (with similar code in the Notify function): 
[0119] 1: if (lamTopFrame) { 



2 : parent.NotifyAII(srcframe,notifyas,value); 

3:} 

4: ... 

[0120] As illustrated in the above code segments, the frame hier- 
archy is maintained by only executing functions of a given 
frame when the local variable indicates it is the top-most 
frame. 

[0121] JSP Reference Generators 

[0122] Once the JavaScript has been declared within a frame, the 
next step is to create the appropriate references and calls 
to automatically register the appropriate listeners and 
provide the "hot spots" for the actioner frame. It should be 
noted that this discussion uses as an example an imple- 
mentation that is oriented towards custom JSP-type Qava 
server page-type) frames that are not contained within a 
portal interface presentation. This is for the purposes of 
illustrating the design and operations of messaging 
portlets and should not be construed to indicate that 
present invention may only be used in this context. 

[0123] A JSP Reference Generator is a fragment of Java server 
page QSP) code that takes input parameters and subse- 
quently generates the HTML code that calls the appropri- 
ate JavaScript functions as necessary. The currently pre- 



ferred embodiment of the present invention includes JSP 
Reference generators for the following: 
[0124] Actioner based on fixed source values (using NotifyAII). 

[0125] Actioner based on a value sourced from a HTML FORM 

text or hidden field (using NotifyAII). 
[0126] Listener based on a target value in a HTML FORM text or 

hidden field. 

[0127] For example, the following illustrates aJSP code fragment 
which can be used to generate the appropriate HTML con- 
taining a link that is used to action a notification: 

[0128] 1: <jsp:include page="ClickAcross-Actioner-FixedValue.js 
P"> 

2: <jsp:param name="notifyas" value="Stock'7> 

3: <jsp:param name="value" value="IBM'7> 

4: </jsp:include> 
[0129] The above JSP code fragment for an actioner generates the 

following HTML code: 
[0130] 1: <a href="" onClick="NotifyAII(thisFrame, 'Stock', 'IBM'); 

return 

false;"> 

2: <img src="images/action_icon.gif' border=0></a> 
[0131] Likewise for a listener, the following JSP code fragment is 
included in the target frame source: 



[0132] 1; <jsp:include page="ClickAcross-Listener-FormTextFiel 
d.jsp"> 

2: <jsp:param name="form" value="TargetForm'7> 

3: <jsp:param name="parameter" value="ParamA'7> 

4: <jsp:param name="registeras" value="Stock'7> 

5: </jsp:include> 
[0133] The above JSP code fragment for a listener generates the 

following HTML code: 
[0134] 1: <script> 

2: Register(thisFrame, 'TargetForm', 'ParamB', 'Location'); 

3: </script> 

4: <table> 

5: <tr> 

6: <td><INPUTTYPE="radio" name="NotifyLocation" valu 
e="l" checked 

onClick="Register(thisFrame, 'TargetForm', 'ParamB', 
'Loca- 

tion');">On <INPUT TYPE="radio" name="NotifyLocation" 
value="0" onClick="UnRegister(thisFrame, "TargetForm", "P 
aramB", 

"Location");">Off 

7: </td> 
8: </tr> 



9: </table> 

[0135] The currently preferred approach of providing JSP Refer- 
ence Generators is one that allows JSP programmers to 
easily incorporate messaging portlet elements in their ap- 
plications. Although there are only a few types of JSP Ref- 
erence Generators they can be easily written to allow for a 
number of different types of actioner source values. To 
implement different types of listener targets it may be re- 
quired to extend the JavaScript functions to allow for dif- 
ferent types of HTML FORM-based registrations. For ex- 
ample, to assign a value to HTML FORM radio button re- 
quires a small amount of additional code in the JavaScript 
functions. 

[01 36] Example of Web application based on messaging portlets 

[0137] Jo illustrate the flexibility of the design and methodology 
the present invention, the following discussion describes a 
small Web application that is based on the use of messag- 
ing portlets. In this example, the Web application is built 
using three messaging portlets that can cooperate based 
on the dynamic content they contain. These three portlets 
are as follows: 

[0138] Symbol List Portlet: The Symbol List Portlet is an aggre- 
gated mPortlet built from a single XML element that 



makes a call to a URL (which happens to be a Java server 
page) that reads a database table for a list of company 
stock symbols. The resulting XML is transformed into 
HTML using a XSL transformation based on a defined XSL 
template. The XSL transformation forms a HTML table with 
a separate row for each different company stock symbol. 

[0139] Address Portlet: The Address Portlet is another aggre- 
gated mPortlet built from a single XML element. However 
the Address Portlet uses a single parameter value in the 
URL to parameterize the company stock symbol that is 
used to read the company's address from the same 
database. Another XSL transformation defined as an XML 
Template is used to display the address as a set of HTML 
FORM text entry fields. The address includes a Post Code 
(or zip code) field. 

[0140] Map Portlet: The Map Portlet is an aggregated Portlet built 
from a single Web element. The Web element is a capture 
of the map sourced from a Post Code entry. Only the Map 
graphic and some of the map controls have been captured 
from the original page. The Post Code has been registered 
as the required entry parameter for this Map Portlet. 

[0141] Conceptually, each of these three portlets performs a dis- 
crete function. However, when defined as messaging 



portlets they can work together to relate the information 
that each is presenting with information presented by the 
other messaging portlets. For example, the Symbol List 
Portlet, when implemented as a messaging portlet, may 
be defined to represent an actioner which creates a notifi- 
cation event based on the click of an actioner icon (or hot 
spot) that is associated with each company stock symbol. 
The Address Portlet represents both a listener and an ac- 
tioner. The Address Portlet registers for the notification of 
a stock symbol event type and re-posts its own HTML 
FORM to re-populate the portlet's address information 
based on the stock symbol received from the notification. 
The actioner of the Address Portlet creates a notification 
event based on the click of an actioner icon (or hot spot) 
associated with the Post Code (or zip code) field. The Map 
Portlet represents a listener which is registered to receive 
notification of a Post Code event type. When a Post Code 
event type occurs, the Map Portlet re-posts its own HTML 
FORM to re-populate the map information based on the 
Post Code received from the notification. 
[0 1 42] Configuration of messaging portlets 

[0143] The configuration of the above-described messaging 

portlets relies on the ability to define additional HTML and 



XSL Templates. A HTML Template acts as a container for a 
messaging portlet and contains references to the individ- 
ual elements that make up the portlet. To represent a 
portlet as a messaging portlet requires the addition of 
calls into the above-described "Register" and "NotifyAII" 
JavaScript functions for the required elements on that 
page. In an alternative embodiment, the portlet automati- 
cally registers and provides notification icons (hot spots) 
and/or links based on values that can be assigned directly 
in forms provided by the system. However, HTML Tem- 
plates may also be used for housing portlets and trans- 
forming them from standalone portlets into messaging 
portlets. 

[0144] For example, the standalone portlet for the above-de- 
scribed Symbol List Portlet can be defined against a stan- 
dard one row by one column (1 x 1) portlet template. 
However, for a messaging portlet a custom user interface 
XSL is created so that it outputs an actioner icon (hot 
spot) for each company symbol returned. The user inter- 
face XSL for a sample Symbol List Portlet is shown below: 

[0145] 1: SymbolList XSL Template: 
2: <?xml version="1.0"?> 

3: <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/X 



SL/Transform" 
version="1.0"> 

4: <xsl:template m ate h = "Symbol Li st"> 
5: <TABLE WIDTH="100%"> 
6: <xsl:for-each select='7/Company"> 
7: <TR> 

8: <TD width="50%" align="right"> 

9: <xsl:value-of select="Exchange'7>.<xsl:value-of 

select="Symbor7> 

10: </TD> 

11: <TD width="50%" align="left"> 
12: <a> 

13: <xsl:attribute name="href'><xsl:text>/clickacros 
s/database/ 

CetSymbolList</xsl:text></xsl:attribute> 
14: <xsl:attribute name="onClick"><xsl:text>NotifyAI 
Kself.name, 
' sym- 
bol", '</xsl:text><xsl:value-of select="Symbor7><xsl:te 
xt>'); 

return false;</xsl:text></xsl:attribute> 

15: <img src="http://msw-k2. Sybase. com:4040/clicka 

cross 



/images/action_icon.gif' border="0'7> 

16: </a> 

17: </TD> 

18: </TR> 

19: </xsl:for-each> 

20: </TABLE> 

21: </xsl:template> 

22: </xsl:stylesheet> 

[0146] The actioner "hot spot" code which provides for sending a 
message in response to a user selecting (e.g., clicl<ing on) 
the hot spot (actioner) is shown above at lines 12-16. 

[0147] The example Address Portlet is also enclosed in a one col- 
umn by one row (1 x 1) HTML Template. The HTML Tem- 
plate code for this sample Address Portlet is shown below: 

[0148] 1: Address 1-1 HTML Template: 
2: <STYLE TYPE="text/css"> 

3: .gridRowHeader {background:#D3E3FC;padding:4px; 
padding-bot- 

tom:Opx;border:lpx solid #FFF;font-size:13px; 

font-family:verdana;font-weight:bold;} 

4: .gridRowA {background:#C4CEDF;padding:4px; 

padding-bot- 

tom:Opx;border:lpx solid #FFF;font-size:13px; 



font-family:verdana;} 

5: .gridRowB {background:#FFFFFF;padding:4px; 
padding-bot- 

tom:Opx;border:lpx solid #FFF;font-size:13px; 

font-family:verdana;} 

6: </STYLE> 

7: <table> 

8: <tr> 

9: <td width = 100%> 

10: <a href="" onClick="NotifyAII(self.name, 'postcode', 
document.address.postcode.value); return false;"><img 
src="/PortletFarm/images/action_icon.gif' border=0></a 
> 

11: </td> 

12: </tr> 
13: <tr> 

14: <td width=100%> 
15: <script> 

16: var amTopFrameset = false; 

17: Register(self.name, 'personalizeForm'+doGetWindowl 
d(), 

'null?null&&symbol&&'+doCetWindowld(), 'symbor); 
18: </script> 



19: </td> 
20: </tr> 
21: <tr> 

22: <td width=100%> 

23: Receive: <INPUT TYPE="radio" name="Notifysymbor' v 
alue="l" checked 

onClick="Register(self.name, 'personalizeForm'+doGetWin 
dowldO, 

'null?null&&symbol&&'+doGetWindowld(), 'symbor);">On 
<INPUT 

TYPE="radio" name="Notifysymbol" value="0" onClick="U 
n Register 

(self.name, 'personalizeForm'+doGetWindowldO, 
'null?null&&symbol&&'+doGetWindowld(), 'symbol');">Off 

24: </td> 
25: </tr> 
26: </table> 

27: <table widtli="100%" cellspacing="0" cellpadding="0" 
> 

28: <tr align="center" valign="middle"> 

29: <td lieiglit="10"><OPContent id="0" name="Content 

" /></td> 
30: </tr> 



31: </table> 

[0149] This above HTML Template is tlie same as tlie original 

standard 1x1 HTML portlet except for the addition of the 
definitions of the listener for the "symbol" notification and 
for the creation of an actioner icon (hot spot) that actions 
the Post Code notification at lines 7-26 above. 

[0150] As shown above at lines 17 and 23, the JavaScript in the 
above HTML references a FORM named "personalize- 
FormNNNN" where "NNNN" is the identifier (ID) of the 
portlet. To obtain the ID of a portlet, a portal interface 
JavaScript function is used that is available from the page 
called "doGetWindowldO". Similarly, at lines 17 and 23 the 
JavaScript references a FORM text field called 
"null?null&&symbol&&NNNN" where "NNNN" is again the 
ID of the portlet. The name of the FORM text field was de- 
rived by viewing the HTML source of the portlet in a pre- 
view prior to assigning the portlet to the new template. 
The Register function can also be modified to automati- 
cally discover both the FORM name and the name of input 
parameters so that this manual process of previewing the 
portlet is not required. 

[0151] The below example Map Portlet is also housed in another 
custom one column by one row (1 x 1) HTML Template. 



The HTML Template code for this sample Map Portlet is 
shown below: 
[0152] 1: YahooMap 1-1 HTML Template: 
2: <STYLE TYPE="text/css"> 

3: .gridRowHeader {background:#D3E3FC;padding:4px; 
padding-bot- 

tom:Opx;border:lpx solid #FFF;font-size:13px; 

font-family:verdana;font-weight:bold;} 

4: .gridRowA {background:#C4CEDF;padding:4px; 

padding-bot- 

tom:Opx;border:lpx solid #FFF;font-size:13px; 
font-family:verdana;} 

5: .gridRowB {background:#FFFFFF;padding:4px; 
padding-bot- 

tom:Opx;border:lpx solid #FFF;font-size:13px; 

font-family:verdana;} 

6: </STYLE> 

7: <table width="100%" cellspacing="0" cellpadding="0"> 
8: <tr> 

9: <td width=100%> 

10: <script language="Javascript"> 

11: var amTopFrameset = false; 

12: Register(self.name, 'personalizeForm'+doGetWindowl 



d(), 

'null?null&&csz&&'+doGetWindowld(), 'postcode'); 
13: </script> 
14: </td> 
15: </tr> 
16: <tr> 

17: <td width=100%> 

18: Receive: <INPUT TYPE="radio" name="Notifysymbol" v 
alue="l" checked 

onClick="Register(self.name, 'personalizeForm'+doGetWin 
dowldO, 

•null?null&&csz&&'+doGetWindowld(), 'postcode');">On <l 
NPUT 

TYPE="radio" name="Notifysymbol" value="0" 
onClick="UnRegister(self.name, 'personalizeForm'+doGet 
WindowldO, 

'null?null&&csz&&'+doGetWindowld(), 'postcode');"Off 
19: </td> 
20: </tr> 
21: </table> 

22: <table width="100%" cellspacing="0" cellpadding="0" 

> 

23: <tr align="center" valign="middle"> 



24: <td height="10"><OPContent id="0" name="Content 
" /></td> 
25: </tr> 
26: </table> 

[0153] This template is also the same as the original standard 1 x 
1 HTML portlet except for the addition of the definitions 
of the listener for the "Post Code" notification shown at 
lines 7-21 above. 

[0154] The FORM text field, the portlet's input parameter, was 
derived from a preview of the portlet prior to assigning it 
this new HTML Template as described above. In this case 
it is called "null?null&&csz&&NNNN" as provided above at 
lines 12 and 18. 

[0 1 55] Example of click across portlets 

[0156] Fig. 6 is an example of a "click across" page 600 contain- 
ing the Symbol List, Address, and Map messaging portlets 
described above. As shown, the Symbol List mPortlet 610, 
the Address mPortlet 620, and the Map mPortlet 630 are 
placed on the same page and interact with each other as 
described below. In the example shown at Fig. 6, the three 
messaging portlets 610, 620, 630 are included in a portal 
interface guest page as presented to the user in one em- 
bodiment of the present invention. 



[0157] As shown at Fig. 6, actioner "hot spots" (icons) 611, 612, 
613, and 614 are shown on the Symbol List mPortlet 610 
against each market symbol. These actioner hot spots 
611-614 each create a notification event passing the as- 
sociated symbol when selected by the user. In this case 
the Address mPortlet 620 is registered as a listener for 
this type of notification. As the user has selected the first 
symbol on the list, the address of this company is re- 
trieved and displayed by the Address mPortlet 620. The 
Address mPortlet 620 also includes an actioner "hot spot" 
(icon) 622 which is associated with the Post Code form 
value. By selecting this actioner, the Map mPortlet 630 is 
refreshed to display a map based the selected Post Code 
(United Kingdom code equivalent to United States zip 
code). 

[0158] The user can also "Click-Across" from the Symbol List 

mPortlet 620 to cause different address information to be 
displayed in the Address mPortlet. For example if the user 
clicked on the action 612 associated with the symbol 
"IBM", the symbol "IBM" is sent by the Symbol List mPortlet 
610 to the Address mPortlet 620. In other words, the 
symbol associated with the actioner hot spot 612 is as- 
signed to the Address symbol parameter, and the Address 



mPortlet 620 is then automatically refreshed based on the 
new parameter. As a result the address of the company 
associated with the selected symbol would be displayed in 
the Address mPortlet 620. 

[0159] The user can also "Click-Across" from the Address mPort- 
let 620 to the Map mPortlet 630 in a similar fashion. Se- 
lecting the actioner "hot spot" 622 assigns the Post Code 
associated with the actioner hot spot to the "csz" parame- 
ter 633 of the IVlap mPortlet 630. The Map mPortlet 630 is 
then automatically refreshed based on the new csz pa- 
rameter to display a map centered on this Post Code. 

[0160] The flexibility of the design of the system of the present 
invention means that other messaging portlets that listen 
for the same notification may also be easily added to a 
page (e.g., page 600). Other mPortlets that were added to 
the page can also refresh themselves in response to a 
Click-Across action in a similar fashion. For example, a 
Stock Price messaging portlet could be added to listen for 
the symbol notification from the Symbol List mPortlet. In 
this case when a Symbol List mPortlet actioner is clicked it 
would refresh both the Address mPortlet and the Stock 
Price mPortlet with the new symbol and content based on 
that symbol would be displayed in both of these 



mPortlets. 

[0161] 

Creation of messaging portlets 

[0162] jhe currently preferred embodiment of the present inven- 
tion provides an interactive "mElement" wizard 
(development tool) that can be used to create messaging 
portlets that will exchange (send and/or receive) mes- 
sages with other elements (portlets). For example, a Web 
application that is being constructed may include a Sym- 
bol List portlet, an Address portlet, and a Map portlet 
similar to those previously described above in this docu- 
ment. By adding "interactive broadcast" and "interactive 
listener" JavaScript routines to these three portlets in ac- 
cordance with the teaching of the present invention, mes- 
saging portlets can be created for sending messages from 
one portlet (or element) that will trigger action in one or 
more other portlets (or elements). This enables a user to 
easily create interactive Web applications that provide 
powerful functionality based on the system and method- 
ology of the present invention which provides for dynami- 
cally matching, labeling, and acting on these messages. 

[0163] The following discussion describes how existing portlets 
or "elements" can be converted into messaging portlets or 
elements (i.e., mPortlets). The following discussion uses 



the example of the conversion of a Web element or portlet 
into a messaging portlet. However, the methodology of 
the present invention may also be used in conjunction 
with other elements or portlets, including database ele- 
ments and XML elements. 
[0164] vVeb portlets (sometimes referred to in the following dis- 
cussion as "elements") created with a content capture 
workbench provided by the system of the currently pre- 
ferred embodiment can be converted into a messaging 
portlet (sometimes referred to below as an "mElement") by 
selecting the desired element and then selecting "mEle- 
ment" from the pop-up menu displayed with a right- 
mouse click. The messaging element wizard provided in 
the currently preferred embodiment of the system pro- 
vides a "wizard page" enabling a user (e.g., developer or 
other knowledge worker) to preview the desired element 
and select from a number of messaging strategies to add 
actions to the element. In many cases the selection of the 
desired messaging strategy is obvious. However, it is pos- 
sible to have a single element that contains several differ- 
ent combinations of anchors, tables, and forms. In this 
event, the user will need to consider the action desired 
and apply the appropriate strategy. Current messaging el- 



ement strategies supported in tlie currently preferred em- 
bodiment of tlie present invention include the following: 

[0165] "Anchor" objects. An anchor object displayed in the wizard 
page may be used to add messaging element actions to 
Web anchors and links within an element. 

[0166] "Grid" objects. A grid object displayed in the wizard page 
can be used to add messaging element actions to Web 
objects with "column and row" formatting. These elements 
are usually the result of a grid capture that has been 
modified with "grid rule" formatting. 

[0167] "Form" objects such as Web "FORM" tags. These objects 
can be captured using a "CELL" capture strategy or a 
"FORM" strategy in the Web capture workbench provided 
by the system of the currently preferred embodiment. 

[0168] "Database" objects for elements that have been created 
using a database capture strategy. 

[0169] "Custom" objects that are unique to a particular installa- 
tion. 

[0170] Using the wizard, the user may select the desired messag- 
ing element strategy and then click on the "Next" button 
to continue the creation of a new messaging element 
(mPortlet). 

[0171] After the user selects the "Next" button, he or she may 



continue implementing one of tlie following mElement 
messaging strategies currently supported in the system of 
the present invention: 

[0172] Link/Anchor Action Message Strategies. A Link/Anchor 
page is provided which includes the following three fea- 
tures: a "preview area" displays a view of the original con- 
tent with additional icons to indicate what message ac- 
tions are being added; an "Assign Message Actions" table 
allows the user to define message actions with a pop-up 
menu and to assign output message names; and an "ac- 
tion icon" (e.g., a red check mark icon) which is displayed 
next to message elements that are "active" and ready to 
send messages. Using the action icon allows the original 
anchor link to remain working within the element. 

[0173] In operation, clicking on the anchor and the link of a given 
element behaves as if there are no messaging actions 
within (or associated with) the given element. However, 
when the "action icon" is selected, the message containing 
the text of the link and the output message name is sent 
to the messaging element's container and then broadcast 
to all other listening elements. 

[0174] The "Assign Message Action" table's pop-up menu cur- 
rently has the following menu items and actions: 



[0175] No Action: The link lias no messaging actions. 

[0176] Send: Send this linl< and output message when the "action 
icon" (e.g., check mark icon) is selected (e.g., clicked on). 

[0177] Send All: Enable all links in the element for action so that 
each link will have an "action icon" icon and output mes- 
sage. 

[0178] Clear: Clear all messaging actions from this element. 

[0179] Test: Bring all JavaScript code into the preview window. 

[0180] When messaging actions have been associated with mes- 
saging elements (mPortlets), a user may select a "Finish" 
button on the wizard. Upon pressing Finish, if a messag- 
ing element (mPortlet) is actionized, an "action icon" (e.g., 
a red check mark icon) is visible in the editor's preview 
page. 

[0181] iyqIj application wizard 

[0182] The system of the currently preferred embodiment also 

provides a "Web Application Builder" tool that can be used 
to create Web applications using a frameset to contain 
multiple elements. Web applications provide a container 
(i.e., mContainer) for messaging elements that communi- 
cate with each other. Elements (portlets) captured from 
different sources with varying strategies can be made to 



communicate with each other using the above-described 
messaging element wizard and then combined using the 
Web Application Builder to create applications that provide 
rich functionality. The Web Application Builder also allows 
users to select from different pre-defined frame layouts to 
design their Web application. 

[0183] The following discussion describes how a Web application 
can be constructed using the Web Application Builder tool 
or wizard. This discussion assumes that all of the ele- 
ments (mPortlets) that are to be used as part of the Web 
application using the Web Application Builder wizard must 
have already been created. 

[0184] In the system of the currently preferred embodiment, the 
Web Application Builder wizard can be started by selecting 
a "Web Application Builder" icon from the toolbar. The 
wizard can also be opened by selecting an "Open New 
Wizard" icon from the toolbar and then selecting "Content 
Development" and "WebApp Builder" from a dialog box. 
Alternatively, a user can select a "WebApp Builder" menu 
item from a Content Capture Workbench menu provided 
by the system. After the wizard is started, a user can se- 
lect a frame layout for the Web application (e.g., by 
choosing an icon of a particular type of frame layout from 



a menu of choices and pressing a "Next" button in the 
wizard). 

[0185] Depending on tlie layout selected, the user may then need 
to select the number of elements. For example, a 3-frame 
layout will require 3 elements to be selected. Currently, 
elements may be selected by highlighting a project name 
to view the contents on a right-hand window pane. Press- 
ing a checkbox next to the project name selects all the el- 
ements by default but it does not make the elements 
viewable. An indication is provided when all of the ele- 
ments have been selected within a project. Elements may 
be deselected by pressing "Deselect All". In the currently 
preferred embodiment, the exact number of elements re- 
quired for the frame layout must be selected before the 
wizard allows the user to continue. 

[0186] After the necessary elements have been selected, a "pre- 
view" pane contains an outline of how the elements will be 
displayed once the Web application is completed. The po- 
sitioning of the elements can be altered by mapping the 
frame name to the name of the element. Drop down 
menus allow the option to choose another location for the 
element. The preview pane may be referenced to find out 
the mapping schema for the element numbers for a par- 



ticular frame layout. The preview pane also reflects any 
changes made to the positioning of the elements. A user 
can also select a "Preview Content" option to view the Web 
application using the actual elements (including their con- 
tents). The completed application can then be saved. In 
the currently preferred embodiment a "save" page is pro- 
vided which enables a user to save the elements and place 
them in the project of their choice. The operations of the 
system of the present invention will next be described in 
greater detail. 
Detailed operation 

[0 1 87] Overview of basic methodology 

[0188] Fig. 7 is a high-level flowchart 700 illustrating the meth- 
ods of operation of the system of the present invention in 
dynamic collection and forwarding of information among 
messaging portlets enabling such mPortlets to process in- 
formation, modify their contents, and/or take action 
based on information received from another mPortlet. The 
following description presents method steps that may be 
implemented using computer-executable instructions, for 
directing operation of a device under processor control. 
The computer-executable instructions may be stored on a 



computer-readable medium, such as CD, DVD, flash 
memory, or the like. The computer-executable instruc- 
tions may also be stored as a set of downloadable com- 
puter-executable instructions, for example, for down- 
loading and installation from an Internet location (e.g., 
Web server). 

[0189] The following discussion uses as an example the conver- 
sion of one or more portlets in an existing static portal 
into interactive messaging portlets. The process begins at 
step 701 with the mapping of message actions to one or 
more existing portlets. For example, a messaging element 
wizard provided in the currently preferred embodiment of 
the present invention may be used to preview the portlets 
to be converted to mPortlets and to select and add mes- 
saging actions to these portlets (e.g., adding "action 
icons" to "actioner" mPortlets that may be selected to 
cause actions to occur in one or more "listener" 
mPortlets). 

[0190] A messaging container (mContainer) is typically created as 
a container for the mPortlet and the mContainer and 
mPortlets are implemented (e.g., as part of a content 
management application or other Web application). As a 
Web page containing the mContainer and mPortlets is 



loaded (e.g., in a browser on a client device), at step 702 
the listener mPortlets register with the registrar and the 
action icons or "hot spots" are generated and displayed to 
"actionize" the actioner mPortlets. 

[0191] A user may then select (e.g., click on) a particular action 
icon of an actioner mPortlet. In response to a user select- 
ing a particular action icon of an actioner mPortlet, at step 
703 the actioner mPortlet sends a message (notification 
event) to the registrar. For example, a messaging portlet 
may be defined to represent an actioner which creates a 
notification event based on the click of an actioner icon 
(or hot spot) that is associated with a company stock sym- 
bol. When the actioner icon is selected, the actioner 
mPortlet packages up the notification data (e.g., informa- 
tion about the company having the stock symbol) and 
passes the notification event to the registrar. 

[0192] When the registrar receives a notification event from an 
actioner mPortlet, at step 704 the registrar looks up the 
registered listener mPortlets that registered to receive this 
notification. In the currently preferred embodiment, the 
binding of a notification event to a listener's registration is 
done using a string value. When a listener registers with 
the registrar, the listener identifies a string value. When 



an actioner issues a notification event to the registrar it 
also includes a string value. The string value provided by 
the actioner is compared to the value of registered listen- 
ers. At step 705, the registrar notifies each of the regis- 
tered listeners (i.e., those with matching values) by pass- 
ing a notification into the listener frame of each registered 
listener mPortlet. At step 706, the notification is pro- 
cessed by the registered listener mPortlet(s). For example, 
an address of the company having the stock symbol may 
be retrieved and displayed in a listener mPortlet in re- 
sponse to the selection of an actioner associated with the 
stock symbol in an actioner mPortlet. 
[01 93] rnPortlethtml loaded into a hidden frame of the container portlet 

[0194] The currently preferred embodiment of the present inven- 
tion utilizes two code libraries to pass messages between 
the messaging portlet elements. Fig. 8 is a diagram show- 
ing a "content container" divided into 4 individual frames. 
As shown at Fig. 8, the content container 800 includes a 
hidden frame 810 and three content frames 820, 830, and 
840. As also shown, a message sent from content frame 
820 is received by the hidden frame 810. The hidden 
frame 810 then sends messages to content frame 830 and 
content frame 840. 



[0195] The hidden frame 810 shown at the top of the content 

container 800 includes the previously-described registrar 
functionality. More particularly, in the currently preferred 
embodiment the hidden frame 810 contains the below 
"mPortlet.html" Javascript code: 

[0196] 1: <HTML> 

2: <SCRIPT LANGUAGE="javascript"> 

3: maxFrames = 10; 

4: function makeFrameArray( size ) 

5:{ 

6: this. length = size; 

7: for (var i = l;i <= size; i++) 

8: this[i] = null; 

9: return this; 

10:} 

11: var myframes = new makeFrameArray(maxFrames); 
12: 

13: function showAlert(){ 

14: alertC'Executing from test.js"); 

15:} 

16: 

17: function registerListener(theFrameName) 

18: { 



19: 

20: for (var i = l;i <= myframes. length; i++) 
21: { 

22: if (myframes[i] == null) 
23: { 

24: myframes[i] = theFrameName; 
25: i = 1000; 

26: } 
27: } 

28: //var winalert = 
win- 

dow.open("","TestWindow","directories=no,location=no, 

menubar=no,status=no,titlebar=no,toolbar=no,width=40 

0, 

height=150,resizeable=no"); 

29: //winalert.document.write("<head><title>mPortlets 
Mes- 

sages</title></head><b>Register Frame as: </b>" + 

theFrameName + " </HTML>"); 

30:} 

31: function sendMsg(theMsg) 

32: { 

33: // alert(theMsg); 



34: for (var i = l;i <= myframes. length; i++) 
35: { 

36: if (myframes[i] != null) 

37: { 

38: 

39: theFrame = "parent." + myframes[i] + ".msgListen(t 
heMsg)"; 

40: // alert(theFrame); 

41: eval(theFrame); 

42: } 

43: 

44: } 

45:} 

46: </script> 
47: </html> 

[0197] The above "mPortlet.html" has the responsibility to wait 
for "registration" of each of the content portlets and to 
send any messages received from a content portlet to 
each of the "listening" portlets registered to receive such 
messages. 

[01 98] rnListenJs file included with each content element 

[0199] As also shown at Fig. 8, content frames 820, 830, and 
840 in the content container (page) 800 include the fol- 



lowing "mListen.js" file which will cause each such content 
frame to register with the mPortlet.html of the hidden 
frame 810 when the page loads in the browser: 
[0200] 1: function sendFormMsgO 
2:{ 

3: var fieldValue = ""; 

4: var fieldName = ""; 

5: var outName = ""; 

6: var msglndex = 0; 

7: for (var i=0;i < acts.length;i++) 

8: { 

9: var c = acts.charAt(i); 
10: if(c!="z") 
11: { 

12: fieldName = document.forms[0].elements[i].name; 
13: fieldValue = document.forms[0].elements[i].value; 
14: 

15: outName = msgOutNames[msglndex++]; 

16: alertC'got to sendFormMsg " + outName + " " + fi 

eldValue); 

17: 

18: } 
19: } 



20 


} 


21 


function msgListen(theMsg) 


22 


{ 


23 


var thelnputString = "" + theMsg; 


24 


var beginFieldMsgLength = 0; 


25 


var theNameMsgLength = 0; 


26 


var nameBeginlndex = 0; 


27 


var fieldValue = ""; 


28 


var fieldName = ""; 


29 


var thisField = ""; 


30 




31 


while (t lie Name l\/lsgLeng til != -1) 


32 


{ 


33 


tlieFieldl\/lsgLengtli = 



thelnputString. indexOf(T,beginFieldMsgLength+l); 
34: if (theFieldlVlsgLength == -1) theFieldlVlsgLength = 
thelnputString. length; // last field in message 
35: thisField = 
thelnput- 
String. substr(beginFieldMsgLength,theFieldMsgLength); 
36: theNameMsgLength = thisField. indexOf("="); 
37: if (theNameMsgLength > 0) 
38: { 



39: theNameMsgLength = theNameMsgLength - name 

Beginlndex; 

40: fieldName = 

thisField.substr(nameBeginlndex,theNameMsgLength); 
41: fieldName = trim(fieldName); 
42: fieldValue = 

thisField.substr(theNameMsgLength+nameBeginlndex+l, 

theFieldMsgLength); 

43: 

44: if (eval("self.document.forms[0]."+ fieldName)) 
45: { 

46: eval("self.document.forms[0]."+ fieldName + ".v 

alue = 

fieldValue"); 

47: //document.forms[0].submit(); 
48: } 
49: } 

50: beginPieldMsgLength = theFieldMsgLengtli; 

51: nameBeginlndex = 1; // after the first field need to 

remove 

"1" delimiter at the beginning of each name 

52: } 
53: 



54:} 
55: 

56: function trim(inputString) { 

57: // Removes leading and trailing spaces from the pas 
sed string. 

58: // Also removes consecutive spaces and replaces it 
with one 

space. If something besides a string is passed 

59: // in (null, custom object, etc.) then return the input 

60: if (typeof inputString != "string") { return inputString 
;} 

61: var retValue = inputString; 

62: var ch = retValue. substring(0, 1); 

63: while (ch == " ") { // Check for spaces at the beginni 

ng of the 

string 

64: retValue = retValue. substring(l, retValue. length); 
65: ch = retValue. substring(0, 1); 
66: } 

67: ch = retValue. substring(retValue.length-l, retValue. I 

ength); 

68: while (ch == " ") { // Check for spaces at the end of 



the string 

69: retValue = retValue.substring(0, retValue.length-1 
); 

70: ch = retValue. substring(retValue. length- 1, retValu 
e. length); 
71: } 

72: while (retValue. indexOf(" ") != -1) { // Note that the 
re are 

two spaces in the string - look for multiple spaces within t 
he 

string 

73: retValue = retValue. substring(0, retValue. indexOf( 
" ")) + 
ret- 
Value. substring(retValue.indexOf(" retValue. length); 

// 

Again, there are two spaces in each of the strings 
74: } 

75: return retValue; // Return the trimmed string back t 
o the user 

76: } // Ends the "trim" function 
[0201] Each Content frame's mListen.js routines will also wait for 
(i.e., listen for) messages from the mPortlet.html of the 



hidden frame (registrar) and insert data received into tlie 
appropriate "INPUT FORIVl" field. This typically causes the 
content of the frame to be dynamically updated based 
upon the message received from another frame. As illus- 
trated at Fig. 8 the contents of content frames 830 and 
840 may be updated based upon the message sent from 
content frame 820. 
[0202] While the invention is described in some detail with spe- 
cific reference to a single preferred embodiment and cer- 
tain alternatives, there is no intent to limit the invention to 
that particular embodiment or those specific alternatives. 
For instance, the system and methodology of the present 
invention may also be used to enhance the ability to con- 
duct information searches by allowing the results of a 
search performed by a first messaging portlet to be sent 
to another search query in another portlet on the same 
page. As another example, the present invention may be 
used to enhance the peer to peer sharing of information 
between two (or more) individuals. Individuals could, for 
instance, exchange messages in a portlet while also shar- 
ing and/or updating information in other messaging 
portlets on the same page. The interactive nature of mes- 
saging portlets enables the development and implementa- 



tion of a wide range of Web applications facilitating infor- 
mation exchanges amongst various users and devices. 
Accordingly, those skilled in the art will appreciate that 
modifications may be made to the preferred embodiment 
without departing from the teachings of the present in- 
vention. 



